前言

昨天我們幫助大家回顧Request Driven的運作流程以及它的優點，用範例簡單說明當系統的複雜度提升的時候，Request Driven所顯現的問題點。

今天呢，會進一步頗析Request Driven的伺服端是怎麼運作的，這個機制的問題怎麼讓開發/維護人員抓頭抓到頭髮掉光光((抓頭。

本系列分為前後兩篇，好了！讓我們開始吧～

Request Driven Architecture的限制

當一個系統的使用者需求和複雜度逐漸增加，Request Driven開始招架不住，產生跟
單體氏架構一樣的問題。

我們沿用昨天的資料管理平台為例：
使用者想要在A資料夾底下建立B資料夾，此時瀏覽器會發送一個帶有payload的POST請求給伺服端，期望將B資料夾的資訊存到db之中。
兩者兼得互動使用RESFUl:

[POST] /api/folders

request body:

{
    'parentId': 'xxx',
    'name': 'B'
}

此時，伺服端提供的create folder的api包含多種不同的操作:

• 呼叫其他api或service
• 重複讀或寫db
• call外部的服務

乍看之下這些操作很合理，其實包含不少值得思考的問題，讓我們將server的操作剖析開，為各位一一解釋:

1. validate: 系統驗證request body是否符合系統要求的規格
2. get folder: call get folder的service確認parent id的資料夾(父資料夾)是否存在
3. query folders: call query的service確認父資料夾底下的所有資料夾名稱有沒有跟使用者想建的重名
4. create folder: 在db裡建立這裡資料並回傳給瀏覽器

所有的操作完成後，文件才成功被建立在db，其中一項操作失敗(ex. 父資料夾找不到, 文件重名)都會導致請求失敗，造成開發跟維護人員掉髮的原因之一。
此外，還有其他幾個問題讓我們留到後篇繼續探討。

總結

本篇開始講到Request Driven伺服端是怎麼運作的，帶大家實際過一遍內部的流程，明天會接著講剩下的問題，之後正式進入Event Drivne的篇章拉!!

好了～～今天就到這邊!!